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ABSTRACT 


Warfighters  conducting  joint  and  coalition  task  force  operations  and  inter-governmental 
agency  operations  supporting  homeland  security  must  interoperate  with  C2/C4I  systems 
that  possess  disparate  mapping/visualization  and  information  management 
infrastructures.  These  C2/C4I  systems  are  generally  built  upon  dissimilar  data 
representations  and  stovepipe  interfaces.  To  achieve  information  superiority  while 
engaged  in  such  operations,  commanders  must  transform  component  C2/C4I  system  data 
into  interoperable  information  and  shared  knowledge,  making  the  result  available  for 
exchange  to  multiple  levels  and  nodes  bases  upon  need  and  choice.  This  level  of 
interoperability  is  critical  for  geo-spatially  and  temporally  registered  operational  object 
information  that  comprises  situation  understanding  aspects  of  a  common  operational 
picture,  which  also  extends  to  supporting  “drill  down”  information.  SAlC’s  Dynamic 
Operational  Object  Registration  Service  (DOORS)  was  developed  in  the  anticipation  that 
a  properly  conceived  C2/C4I  vocabulary  of  domain  knowledge  representation,  supported 
by  an  ontology-driven  adaptive  system,  and  employing  meta-data  based  translation 
services  (mapping  of  data  from  each  participating  system  to  a  common  representation) 
will  provide  the  requisite  basis  for  a  network-centric  enterprise  data  mediation  service 
that  addresses  current  interoperability  challenges.  DOORS  provides  the  mechanism  to 
exchange  interoperable  information  for  joint/combined  task  force  operations  according  to 
a  register-publish-subscribe  metaphor  that  reflects  the  commander’s  information 
exchange  requirements. 
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A  NETWORK-CENTRIC  ENTERPRISE  SERVICE  FOR 
MEDIATION  AND  INTEROPERABILITY:  THE  DYNAMIC 
OPERATIONAL  OBJECT  REGISTRATION  SERVICE 

(DOORS) 


INTRODUCTION 

Achieving  interoperability  amongst  the  vast  assortment  of  systems  used  for  Command 
and  Control  (C2)  and  Command,  Control,  Communications,  Computers  and  Intelligence 
(C4I)  supporting  the  warfighter’s  decision-making  process  remains  the  most  critical 
problem  facing  military  operations. 

Historically,  this  problem  has  been  approached  by  codifying  and  developing  pair-wise 
system-to-system  interfaces  consisting  of  highly  structured  and  inflexible  data  exchanges 
via  messaging  or  remote  procedure  calls  (RPCs),  or  worse,  by  utilizing  some  lesser 
means  such  as  semi-automated  or  manual  data  transfer.  As  the  number  of  systems 
brought  into  play  during  today’s  joint  and  combined  force  operations  proliferates,  this 
predicament  is  made  worse,  resulting  in  an  increasingly  complex  tangle  of  information 
exchange  requirements  -  the  so-called  n2 problem. 

This  interoperability  problem  is  most  pronounced  when  considering  the  situation 
awareness  (SA)  and  situation  understanding  (SU)  elements  of  C2/C4I  functional 
architectures,  which  strive  to  represent  geo-spatially  and  temporally  referenced 
information  critical  to  the  decision-making  process.  Often  referred  to  as  a  Common 
Operating  Picture  (COP),  this  capability  is  intended  to  provide  a  coherent,  consistent, 
relevant,  and  unambiguous  view  of  the  bcittlespace  infosphere  containing  the  information 
required  to  achieve  decision  superiority  in  a  timely  fashion.  However,  the  efficient 
construction  of  a  true  COP  has  been  hindered  by  fragmented  conceptions  of  COP  domain 
representations,  and  the  furtherance  of  individually-developed  evolutionary  and  legacy 
“stovepipe”  systems. 

Past  approaches  to  this  interoperability  challenge  have  focused  upon  providing 
standardized,  underlying  representations  for  all  participating  C2/C4I  systems;  that  is,  a 
common  object/data  model  or  database.  If  implemented  uniformly,  this  tightly  coupled 
method  allows  for  the  synchronization  of  information  between  all  sources  and  sinks, 
providing  a  unified  view  of  the  represented  domain  and  preserving  data  and  transactional 
integrity.  While  progress  has  been  made  using  multiple  variations  of  this  methodology, 
funding  and  schedule  constraints  inherent  in  the  acquisition  process  have  served  to  hinder 
the  resolution  of  the  interoperability  problem  via  the  migration  of  C2/C4I  systems  to 
common  models.  Further  difficulties  with  this  approach  include: 

•  Development  and  maintenance  of  common,  standardized  C2/C4I  models  are 
exhaustive  undertakings,  prone  to  colossal  management  schemes. 
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Interoperability  fissures  will  be  introduced  whenever  domain  gateways  are 
required. 

•  Common,  standardized  C2/C4I  models  evolve  by  nature,  and  it  is  prohibitively 
expensive  for  all  participating  C2/C4I  systems  to  continually  modify/update. 
Interoperability  fissures  will  be  introduced  whenever  baseline  divergence  occurs. 

•  Common,  standardized  C2/C41  models  do  not  allow  for  the  rapid  integration  of 
non-participating  C2/C4I  systems.  Interoperability  fissures  will  be  introduced 
whenever  non-conformant players  arrive  on  the  scene. 

•  Elements  within  the  C2/C4I  domain  defy  common,  standardized  representation. 
Interoperability  fissures  will  be  introduced  whenever  vocabulary  mismatch 
occurs. 

The  current  emphasis  on  defense  transformation  to  network-centric  warfare  (NCW) 
systems  and  network-centric  enterprise  services  (NCES)  that  draw  upon  a  global 
information  grid  (GIG)  of  available  knowledge  demands  a  highly  interoperable  fabric  of 
exposed  information,  services,  and  systems. 

More  recent  developments  aimed  at  providing  interoperability  amongst  participating 
C2/C4I  systems  have  shifted  the  focus  from  object/data  standardization  to  mediation  (or 
integration)  via  transformational  mapping  techniques.  In  this  scenario,  a  common  object 
model  is  introduced  as  a  instantiated  NCES  that  mediates  the  differences  in  semantic 
representations  between  participating  system-specific  schemas,  by  establishing  the  map 
between  the  participant  system’s  local  vocabulary  and  a  common  C2/C4I  vocabulary 
resident  within  the  mediation  service  (thereby  acting  as  a  semantic  gateway  between 
disparate  representations).  Initiatives  such  as  the  Office  of  the  Secretary  of  Defense’s 
(OSD)  Family  of  Interoperable  Pictures  (FIOP),  the  Joint  Chiefs  of  Staffs  (JCS) 
Situational  Awareness  Data  Interoperability  (SADI)  project,  and  the  JCS  Joint 
Warfighting  Capabilities  Assessment  (JWCA)  Joint  Task  Force  (JTASK  FORCE)  C2 
Interoperability  Study,  along  with  related  agency/service  programs,  such  as  DISA’s  DII 
COE/NCES,  GCCS/Joint  C2  System,  and  DOD  Data  Emporium/eXtensible  Markup 
Language  (XML)  Registry  have  been  pursuing  similar  directions. 

Semantic  mapping  can  be  static,  where  system  developers  use  configuration  applications 
such  as  ontology  builders  to  collect  and  explicitly  transform  their  systems’  object  model 
into  that  of  the  mediation  service;  or,  dynamic  where  an  expert  system  and  knowledge 
base  assists  in  varying  degrees  of  automatic  mapping  upon  the  registration  of  new 
participant  system  vocabularies.  These  loosely  coupled  methods  leverage  semantic 
representation  efforts  related  to  common  models,  yet  are  targeted  at  providing 
interoperability  “glue”  rather  than  forcing  conformance  upon  multiple  participant  system 
underlying  representations.  Further,  there  need  not  be  a  single  type  of  mediation  NCES; 
sage  governance  can  give  rise  to  multiple,  interoperable  mediation  services  focused  upon 
communities  of  interest  (COI).  Benefits  of  the  mediation  NCES  approach  include  the 
following: 
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•  The  constituent  semantic  mappings  and  resultant  ontology  of  the  mediation  NCES 
are  reusable.  Systems  developers  provide  their  system-specific  translation  maps 
once,  and  then  the  participant  system  can  interoperate  via  the  mediation  NCES 
with  all  other  participant  systems.  Seamless  interoperability  will  be  fostered 
despite  local-local  vocabulary  mismatches. 

•  The  mediation  NCES  provides  a  reductive  interface,  thus  systems  developers  may 
provide  their  system-specific  translation  maps  via  one  interface,  and  then  the 
participant  system  can  employ  the  mediation  NCES  for  all  other  required 
interfaces.  Seamless  interoperability’  will  be  fostered  via  simplified,  efficient 
software  development  efforts,  and  promote  baseline  convergence. 

•  The  mediation  NCES  provides  a  flexible  model  for  registering  local  vocabularies 
for  local  domains,  providing  a  plug-n-play  modular  interface.  This  enables  the 
inclusion  of  new  participant  systems  into  the  mediation  scheme  via  ontology 
building  and  semantic  mapping  via  declaration.  Participant  systems  are  free  to 
provide  either  as  much  or  as  little  exchange  of  their  information  as  warranted. 
Seamless  interoperability’  will  be  fostered  via  focusing  upon  shared  exchange  of 
truly  common  objects. 

•  The  mediation  NCES  allows  for  local  vocabularies  for  local  domains,  allowing 
participant  systems  to  isolate  their  schema  from  changes  induced  by  invasive 
interoperability  measures  and  evolving  standards.  Seamless  interoperability  will 
be  fostered  via  focusing  upon  the  exchange  of  truly  common,  shared  objects. 


TECHNICAL  APPROACH 
System  Concept 

DOORS  addresses  the  interoperability  problem  by  providing  a  mediation  NCES 
categorized  by  three  operational  directions: 

1.  Translation  of  C2/C4I  system-specific  objects  at  the  interface  boundary  into 
“ Interoperable  Information”  according  to  accepted  standards  for  common 
representation. 

2.  Exchange  of  ‘‘Interoperable  Information”  for  joint/combined  task  force 
operations  according  to  a  register-publish-subscribe  metaphor  that  reflects  the 
commander’s  information  exchange  requirements. 

3.  Assured  delivery  encompassing  reliable,  near  real-time  dissemination  of  DOORS- 
exchanged  information  in  task  force-focused  operational  networks. 

Once  fully  realized,  the  DOORS  program  would  function  as  an  Infrastructure 
NCES  existing  within  the  Global  Information  Grid  (GIG).  Each  disparate  participant 
system  (a  DOORS  participant  system  is  defined  as  a  warfighter’s  C4ISR,  C3I,  C2,  M&S, 
or  other  system  of  interest  which  has  implemented  a  DOORS-conformant  interface) 
registers  information  it  will  provide  to  other  participant  systems.  The  DOORS  Service 
enables  information  exchange  by  providing  a  mediation  and  brokering  layer  between 
disparate  systems,  translating  from  a  system-specific  set  of  warfighter  objects  to  a 
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common  domain  knowledge  representation  or  ontology  for  dissemination  to  interested 
parties  and  subsequent  translation  into  the  native  formats  of  downstream  participant 
systems  connected  to  the  DOORS  NCES.  DOORS  will  allow  tailored  views  of 
information  to  be  shared  among  users  with  disparate  C2  systems  operating  within  a 
seamless  task  force  environment,  providing  the  commander  of  the  task  force  the  ability  to 
visualize  and  drill  down  into  information  supplied  by  DOORS-enabled  C2  systems 
employed  by  his  component  commanders  during  operations.  The  DOORS  NCES  will 
leverage  existing  dissemination  and  replication  mechanisms  within  the  network;  and 
incorporate  an  inherent  capability  to  ensure  reliable  delivery  of  interoperable  information. 
Three  technology  initiatives  will  support  the  DOORS  NCES: 

1.  Formation  of  an  XML-based  C2/C4I  Vocabulary  or  Common  Ontology 
encompassing  known  standards  for  representation  of  C2/C4I  domain  knowledge. 

2.  Metadata-based  Ontology  Translation  between  disparate  C2  systems  via 
Semantic  Mapping  techniques,  utilizing  the  evolving  body  of  knowledge  known 
as  the  Semantic  Web,  including  the  DARPA  Agent  Markup  Language 
(DAML)  and  Ontology  Inference  Language/Ontology  Interchange  Layer  (both 
OIL  =>  DAML+OIL),  the  Resource  Description  Framework  (RDF),  etc. 

3.  Exploitation  of  best  of  breed  Distributed  Information  Architectures  for 
interoperability,  scalability,  and  dissemination:  Hybrid  Peer-to-Peer  object 
exchange  models,  Web  Services,  etc. 


Once  operational  on  the  GIG,  participant  systems  with  DOORS-compliant  interfaces  can 
register  with  DOORS,  publishing  objects  [e.g.  map  overlays  containing  symbols]  and 
providing  them  to  the  DOORS  Web  Service  [i.e.  server]  for  advertisement  to  other 
participant  systems.  Operators  throughout  the  network  may  then  use  a  DOORS  Client 
Agent  resident  on  their  system  to  access  these  objects  until  the  provisioning  system  either 
denies  access  to  the  objects  or  opts  to  delete  them  from  the  DOORS  Web  Service. 

By  introducing  the  above  concepts,  DOORS  allows  multiple,  disparate  systems  with 
distinct  architectures  [i.e.  presentation/mapping,  business  logic  information  management, 
and  data  persistence  component  subsystems,  etc.]  to  exchange  information  via  a  single 
interface  rather  than  construct  and  manage  N  multiple  bi-lateral  interfaces,  i.e.  an 
additional  interface  for  each  system  it  is  required  to  exchange  information  with.  The 
DOORS  NCES  acts  as  a  gateway  that  translates  system-specific  information  from  client- 
side  agents  into  its  C2/C4I  vocabulary  (or  common  ontology)  and  publishes  the  results 
for  subscribers  to  retrieve  upon  notification  by  the  service.  Assuming  the  DOORS  Web 
Service  is  available  throughout  the  GIG  network,  this  has  the  affect  of  reducing  N2 
interfaces,  thereby  alleviating  network  communication  by  trunking  and  routing  system- 
to-system  information  exchange  through  the  DOORS  NCES.  Figure  1  illustrates  this 
principal. 
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C2/C4I  systems  are  producers  and  consumers  of  a  wide  variety  of  operational  object 
categories  and  will  naturally  register,  publish,  and  subscribe  to  those  objects  that  have  a 
representation  closely  aligned  with  their  own  internal  data  structures.  DOORS  employs 
semantic  mapping,  therefore  object  exchange  can  occur  between  disparate  system- 
specific  representations  as  well  as  a  variety  of  object  formats  and  standards.  Thus,  the 
DOORS  NCES  provides  data  mediation  between  systems  created  for  a  range  of  purposes 
or  encompassing  diverse  standards.  For  example,  operational  C2  systems  may  be  driven 
by  modeling  &  simulation  systems,  a  JVMF  message  provided  by  one  system  may  be 
translated  into  an  MIL-STD-2525  overlay  on  another.  The  variety  of  object  exchange 
solutions  addressed  by  the  DOORS  technical  approach  to  schema  translation  is  illustrated 
in  Figure  2. 
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Figure  2  - 

“ The  Conceptual  Context  for  Object  Exchange ” 


System  Architecture 

A  top-level  DOORS  systems  architecture  is  illustrated  in  Figure  3.  Residing  within  the 
cloud  representing  the  GIG  network  and  other  NCES  infrastructure  components,  the 
DOORS  Web  Service  may  be  federated  to  leverage  the  synchronization  and  replication  of 
published  objects  in  accordance  with  “power  to  the  edge”  concepts  such  as 
Task/Post/Process/Use  (TPPU)  network-centric  operations  described  by  DOD’s 
Assistant  Secretary  of  Defense  for  C3I. 


DOORS  was  conceived  as  a  network-centric  enterprise  service  and  embraces  Web 
Services  for  its  technological  underpinnings  as  depicted  in  Figure  4,  building  upon  the 
Sun  Microsystems ’s  Java/J2EE™  architecture  with  Simple  Object  Access  Protocol 
(SOAP)  interfaces  described  by  the  Web  Service  Definition  Language  (WSDL). 
Optionally,  the  DOORS  NCES  may  be  advertised  on  the  GIG  via  a  UDD1  repository.  For 
more  infonnation  about  Web  Services  and  its  component  specifications,  please  see  the 
World  Wide  Web  Consortium  (W3C®)  at  http://www.w3c.org/. 


Figure  4  - 

“Use  of  XML  Technologies/Specifications  in  DOORS 
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Each  type  of  participant  system  is  assumed  to  have  a  unique  combination  of  components 
spanning  the  presentation  (map  displays,  editors,  report  generators),  business 
logic/information  management  (n-tier  applications,  common,  and  support  services),  and 
data  persistence  (databases,  file  systems)  architectural  layers  that  adhere  to  well-defined 
yet  potentially  dissimilar  internal  representations  of  information.  Therefore,  each 
participant  system  is  required  to  create  and  host  a  system-specific  DOORS  Client  Agent; 
This  agent  provides  the  interface  connection  to  any  public  interface  offered  by  the 
participant  system,  whether  it  be  an  application  programmer’s  interface  (API),  a  database 
connection  object,  or  other  structured  content  readable  by  the  DOORS  Client  Agent  such 
as  a  delimited  file  or  XML  document.  The  agent  may  bind  to  any  technology  required  to 
interface  with  the  participant  system,  yet  must  possess  the  SOAP/XML  interface  to 
subscribe  to  the  DOORS  Web  Service.  The  system-specific  DOORS  Translation  Agent 
provides  schema  translation  according  to  the  semantic  mapping  between  the  participant 
system’s  knowledge  representation  and  the  DOORS  common  ontology  or  C2/C4I 
Vocabulary.  For  each  Participant  System  ( 1-N ),  DOORS  proffers  a  SOAP/XML 
interface  comprised  of  two  constituent  sections: 

•  DOORS  Service  Commands  -  for  registration,  notification,  flow  of  control,  and 
other  system-level  commands  common  to  all  DOORS  Client  Agents. 

•  DOORS  Object  Exchange  -  for  exchange  of  operational  object  information, 
including  attributes  and  methods  defined  by  a  system-specific  DOORS 
Translation  Agent. 

Within  the  DOORS  Web  Service  proper  are  the  following  major  subsystems: 

•  Object  Exchange  and  Registration  Management  -  for  management  of  the 
registration,  publish,  and  subscribe  mechanisms  that  govern  communications  with 
the  connected  DOORS  Client  Agent(s)  hosted  on  participant  systems,  issuance  of 
DOORS  Service  Commands,  and  DOORS  Object  Exchange  between  the 
participant  system(s)  and  DOORS  Web  Service  instantiation(s).  This  subsystem 
manages  the  objects  actively  being  shared  within  DOORS,  and  any  system 
defined  hierarchical  containers  of  objects  e.g.  overlays,  folders,  filter  results,  etc.; 
it  also  controls  an  “event  horizon”  simulation  time  service  and  provides 
information  necessary  to  configure  DOORS  the  Client  Agent(s)  and  its  respective 
SOAP/XML  interface(s). 

•  Translation  and  Ontology  Management  -  for  definition  of  the  common 
ontology  schema  representing  the  C2/C4I  Vocabulary,  and  semantic  mapping 
between  participant  systems  and  the  common  ontology.  This  subsystem  also 
manages  the  DOORS  Translation  Agents  in  the  performance  of  the  static  system 
developer  defined  [drag-n-drop]  semantic  mapping  of  meta-data  or  the  more 
dynamic  adaptive  rule  based  semantic  mapping  of  meta-data,  which  matches  the 
schema  of  a  newly  registered  interface  to  the  common  ontology  by  employing 
expert  system  concepts.  Is  this  way,  a  more  robust  and  expansive  C2/C4I 
Vocabulary  may  be  built  over  time  from  the  resultant  aggregation  and  subsequent 
reduction  for  each  successive  participant  system  ontology  schema  introduced. 
Finally,  this  subsystem  performs  verification  and  generation  of  DOORS 
Translation  Agents,  including  their  internal  objects  and  SOAP/XML  interfaces. 
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•  Data  Persistence  -  for  persistence  of  the  DOORS  Web  Service  management 
information  and  common  ontology  schema,  as  well  as  the  optional  asynchronous 
storage  of  shared  DOORS  objects.  DOORS  may  employ  both  relational  and 
XML  databases  for  persistence. 

The  DOORS  provides  a  Web  Viewer  consisting  of  GUIs  for  session  management 
(registration,  publish,  subscribe),  administration,  and  semantic  mapping  and  translation 
tools.  A  master  map  view  based  upon  BBN’s  OpenMap™  allows  users  that  neither 
contribute  nor  or  possess  a  participant  system  to  view  OpenGIS™  Consortium  compliant 
geo-registered  information  being  actively  shared  by  the  DOORS  Web  Service.  This 
master  map  view  is  available  as  either  a  lightweight  client  or  from  within  a  web  browser. 
The  DOORS  Web  Service,  its  SOAP/XML  interface,  and  supporting  GUIs,  and  its  basic 
security  model  for  user  authentication  and  discretionary  access  control  are  built  upon 
WebLogic  Platform™ from  BE  A  Systems. 

DOORS  Ontology  and  Semantic  Mapping 

An  ontology  provides  a  fonnal  means  to  conceptualize,  represent,  and  structure  domain 
knowledge  for  a  community  of  interest,  and  the  schema  for  that  ontology  can  establish 
the  instrument  to  unify  discourse  within  the  domain  thereby  facilitating  interoperable 
information  exchange  and  knowledge  sharing.  An  ontology  specifies  the  definitions  of 
classes,  relationships,  and  processes  in  a  declarative  sense,  and  the  resultant  knowledge 
base  it  represents  fonns  a  vocabulary  by  which  to  describe  it. 

Advances  in  XML  related  technologies,  including  further  refinement  of  XML  Schema, 
RDF  and  RDF  Schema,  and  DAML+OIL  as  depicted  in  Figure  4,  have  contributed 
powerful  new  tools  upon  which  to  build  ontologies  such  as  the  DOORS  C2/C4I 
Vocabulary.  XML  tagging,  customarily  used  for  meta-data  description,  is  has  become  an 
increasingly  popular  method  to  provide  object  encapsulation  of  attributes  and  methods 
and  derive  meaning  from  semantics,  i.e.  construct  ontological  schemas  for  knowledge 
representation,  express  rules  for  axiomatic  behavior,  or  formulate  logic  for 
deductive/inductive  reasoning.  Indeed,  DOORS  exploits  semantic  mapping  from 
multiple  participant  data  sources  schemas  into  a  DAML+OIL  based  common  ontology 
for  a  data  mediation  service,  and  documents  the  translation  between  local  participant  and 
common  ontology  schemas. 

DAML+OIL  is  a  W3C®  specification  for  the  composition  and  management  of  ontologies, 
and  builds  upon  RDF  and  XML  Schema.  RDF  is  based  upon  predicate  calculus  and  graph 
theory  and  provides  a  semantic  network  of  Subject -Predicate-Object  RDF  triplet 
statements  [Resource  has  Property  with  Value],  a  useful  syntax  for  the  development  of  a 
hierarchical  object  model  within  DAML+OIL  (similar  in  nature  to  that  of  RDF  Schema) 
and  contributes  the  bounds  of  the  vocabulary’s  domain  and  range.  DAML  provides 
description  logic  to  reduce  semantics  into  computable  taxonomies,  defines  classes  and 
properties,  reinforces  domain,  range,  and  cardinality,  and  enhances  machine  readability. 
OIL  adds  reasoning  by  stating  sufficient  and  necessary  conditions  for  belonging  or 
exclusion.  Unified  and  revised,  DAML+OIL  provides  rich  modeling  primitives, 
incorporates  XML  Schema  data  typing,  and  separates  object  from  data  type  instances  via 
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exclusive  membership  rules.  OWL,  the  Web  Ontology  Language,  is  another  refinement 
of  DAML+OIL  under  consideration  by  the  W3C®  that  could  find  its  way  into  future 
DOORS  development  activities. 

In  composing  the  DOORS  common  ontology,  a  knowledge  representation  schema  was 
formed  that  encompasses  generally  accepted  and  widely  adopted  source  schemas  from 
the  C2/C4I  domain.  Figure  5  illustrates  broad  categories  of  operational  objects 
(symbols,  messages,  objects,  relational  entities,  etc.)  and  their  respective  standards 
represented  within  this  ontology.  For  example,  Joint  Common  Database  (JCDB) 
battlefield  objects  (BFOs)  fonn  the  core  set  of  relational  DOORS  operational  objects. 


DOORS  Domain 
Knowledge  Respresentation 
Schema 

for  Common  Ontology 
(with  representative  decomposition) 


Operational  Object 


Symbol  _  Message  _  Object  _ Relational _  Mod/Sim  _  XML 


UmIL-STD-2525 

-USMTF 

-DOM 

—  ATCCIS  Generic  Hub 

-  DIS  L  DOD  XML  Registry 

1—  MIL-STD-1477C 

-  JVMF 

-  JTC 

L  LC2IEDM 

Lhla 

Structured  E-Mail 

ArcObjects 

—  C2  Core  DM 

—  CMMS 

-C4I  Arch  DM 

-FOM 

Source  Schemas 

•—JCDB 

Lsom 

—  Organization 

—  Feature 

—  Facility 

—  Person 

—  Materiel 


“ The  DOORS  Domain  Knowledge  Base  Hierarchy  ” 


As  adopters  of  DOORS  add  their  system-specific  schema  maps  to  the  Translation  and 
Ontology  Management  subsystem  in  the  process  of  creating  DOORS  compliant  interfaces 
to  participant  systems,  it  is  also  possible  the  common  ontology  describing  the  DOORS 
C2/C41  Vocabulary  lacks  the  structure  to  sufficiently  describe  a  concept  that  is  important 
to  the  participant  system  and  the  C2/C4I  domain  in  general.  In  such  cases  the  structure 
may  be  added  to  the  common  ontology.  In  this  way,  more  robust  and  expansive  C2/C4I 
Vocabulary  may  be  built  over  time  from  the  resultant  aggregation  and  subsequent 
reduction  for  each  successive  participant  system  ontology  schema  introduced. 


Figure  6  depicts  the  semantic  mapping  between  two  subject  knowledge  bases  used  by 
operational  C2  systems  involved  in  the  DOORS  operational  prototype:  the  Global 
Command  and  Control  System’s  (GCCS)  Common  Operational  Picture  (COP)  Track 
Database  Manager  (TDBM)  and  the  Army  Battle  Command  System’s  Common  Tactical 
Picture  (CTP). 
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Figure  6  - 

“ Semantic  Mapping  for  Ontology  Mediation/Schema  Translation  ” 

Semantic  mapping  allowed  tracks  from  the  fonner  schema  to  be  translated  into 
organizations  in  the  latter  schema  by  way  of  DOORS  Translation.  Semantic  mapping 
defines  how  to  transfonn  source  ontology  schemas  into  the  DOORS  common  ontology 
schema.  XSLT  has  been  employed  for  parsing  schema  elements  and  mapping 
translations.  Generally,  these  mappings  are  constructed  according  to  schema  element 
type  (object  class,  data  types),  cardinality  (one-to-one,  one-to-many,  many-to-one), 
condition  (specified  value,  Boolean  True/False,  etc.),  or  customized  translation  which 
applies  some  function  operating  on  the  participant  system  schema  to  reconcile  it  with 
concepts  expressed  in  the  common  ontology.  Mapping  of  DAML+OIL  classes  and 
properties  use  rules  templates  of  RDF  triplets.  XPath  expressions  identify  actual  element 
values,  which  are  mapped  into  subject/object  classes  contained  in  the  ontology.  Term 
mapping  distinguishes  containerTank  from  weapon  Tank,  and  so  forth.  After  validation 
of  domain  and  range  values  occurs,  a  DOORS  Translation  Agent  provides  a  SOAP/XML 
interface  to  a  DOORS  Client  Agent,  enacting  the  interface  between  a  participant  system 
and  the  DOORS  Web  Service.  Figure  7  demonstrates  a  very  simple  case  of  semantic 
mapping  between  a  participant  system’s  rectangle  object  and  the  DOORS  common 
ontology  primitive  somRectangle. 
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Figure  7  - 

“ Sample  DOORS  Translation  Mapping  ” 


The  DOORS  Web  Service  provides  simple  GUIs  for  static  semantic  mapping  by 
experienced  system  developers  [i.e.  they  are  not  intended  for  operators,  but  for  systems  or 
software  engineers].  The  completion  of  the  mapping  process  is  signified  by  submission 
of  the  map  to  the  DOORS  Translation  Agent,  which  makes  use  of  expert  system 
techniques  for  code  generation,  constructing  the  serializable  package  as  shown  in  Figure 
8  that  is  used  as  the  basis  for  the  object  exchange  portion  of  the  SOAP/XML  interface. 


Figure  8  - 

“ Sample  DOORS  Translation  Agent  Code  Generation  ” 
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The  DOORS  Translation  and  Ontology  Management  subsystem  foresees  that  dynamic 
semantic  mapping  of  meta-data  via  adaptive  rule  based  semantic  mapping  of  meta-data 
that  automatically  seeks  maps  between  the  schema  of  a  newly  registered  participant 
systems  and  the  common  ontology  by  employing  expert  system  concepts  will  provide  a 
practical  technique  to  build  up  the  C2/C4I  vocabulary.  A  variety  of  “best  fit”  scoring 
methods  such  as  Bayesian  reasoning,  distance  vectors,  etc.  are  being  employed  with  great 
success  in  this  area,  leaving  the  systems  developers  to  deal  with  only  outlying 
mismatches  rather  that  manually  map  entire  knowledge  bases. 

RESULTS 

A  DOORS  operational  prototype  was  successfully  demonstrated  during  the  Joint 
Warfighter  Interoperability  Demonstration  of  2002,  featuring  the  exchange  of  overlay 
related  objects  between  an  early  release  version  of  Integrated  C4I  System  Framework 
(ICSF)  based  Common  Operational  Picture  being  incorporated  into  the  Defense 
Information  System  Agency’s  GCCS-Joint  4.x,  and  the  Joint  Mapping  Toolkit  (JMTK) 
based  Common  Tactical  Picture  (CTP)  found  in  the  Anny  Battle  Command  System  6.x. 
A  DOORS  NCES  instantiation  was  hosted  on  the  Coalition  Wide  Area  Network 
(CWAN)  located  in  the  Advanced  Information  Technology  Services  -  Joint  Program 
Office  in  Arlington,  Virginia;  the  ICSF  GCCS-COP  was  located  with  the  Joint  Forces 
Maritime  Component  Commander  (JFMCC)  at  Space  and  Naval  Warfare 
(SPAWAR)/San  Diego,  California  and  the  JMTK  ABCS-CTP  was  located  with  the  Joint 
Forces  Land  Component  Commander  (JFLCC)  at  NSWC/Dahlgren,  Virginia  as  part  of  a 
Brigade  Tactical  Operation  Center’s  (BDE  TOC)  complement  of  Maneuver  Control 
System  (MCS)  platforms. 

Using  straightforward  GUIs  like  those  in  Figure  9,  JWID  operators  were  able  to 
collaborate  between  sites  using  shared  overlay  graphics  thereby  fulfilling  the  goals  of  the 
JWID  Mission  Scenario  Event  List  (MSEL)  and  JWID  interoperability  objectives. 
DOORS  provided  the  ability  to  share  the  BDE  TOC  blue  and  red  pictures  with  the 
JFLCC  and  then  coordinate  with  the  JFMCC  in  the  conduct  of  joint  task  force  operations. 
DOORS  supplied  the  mechanism  to  exchange  interoperable  information  that  reflected  the 
commander’s  information  exchange  requirements,  contributing  BDE  level  battlefield 
graphics  and  unit  information  to  GCCS,  a  feat  not  able  to  be  accomplished  with  the 
neither  current  production  tested  nor  fielded  system  baselines.  Currently,  the  Army 
interface  with  joint  systems  is  limited  to  the  data  that  is  translated  from  the  Global 
Command  and  Control  System-Army  (GCCS-A)  into  the  JCDB  and  vice  versa.  The 
COP-CTP  integrated  picture  is  currently  not  fully  realized  between  the  GCCS-COP  and 
the  ABCS-CTP,  because  not  all  of  the  data  representing  the  CTP  extracted  from  the 
JCDB  are  capable  of  storage  within  the  COP  and  its  TDBM  for  viewing  on  GCCS-COP. 
In  addition,  the  current  implementation  of  messaging  is  limited,  and  the  fidelity  of  data 
provided  via  the  messaging  applications  does  not  represent  the  totality  of  what  is 
available. 
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Figure  9  - 

“ DOORS  Object  Exchange  and  Registration  Management  GUIs ” 


Figure  10  displays  a  sample  ABCS-CTP  map  overlay  provided  by  an  MCS  operator  that 
was  registered  and  published  via  the  DOORS  Web  Service. 


Figure  10  - 

“ DOORS  Shared  Objects  Displayed  on  the  Army  Battle  Command  System  (ABCS)  Common  Tactical  Picture  (CTP)” 


Figure  |ll  displays  the  resulting  overlay  on  the  ICSF  GCCS-COP  infrastructure.  Apart 
from  local  rendering  capabilities  of  the  mapping  software,  the  overlays  are  identical,  and 
provide  shared  knowledge  suitable  for  collaboration  between  geographically  separated 
operators.  Using  the  Defense  Collaboration  Tool  Suite  (DCTS),  the  JWID  operators  to 


Comment:  Bonus  Points  for  those  who 
get  the  operational  mistake  here. ... 


Comment:  Note  that  ICSF  cannot 
properly  render  the  FLOT  curves 
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efficiently  created  courses  of  action  to  conduct  military  operations  based  upon  an 
expanded  common  operational  picture. 


Figure  11  - 

“ DOORS  Shared  Objects  Displayed  on  the  Global  Command  and  Control  System  ( GCCS) 

Integrated  C4I  System  Framework  (ICSF)” 

The  following  table  summarizes  some  of  the  key  design  goals,  technical  approaches,  and 
results  of  the  DOORS  technical  approach: 


Design  Goal 

Technical  Approach 

Results/Comments 

Reduce  N2 
interfaces 

Data  mediation  via 
schema  mapping  and 
translation 

DOORS  Web  Service 
gateways  available 
within  the  NCES  GIG 

Reduction  N2  =>  N 

Semantic  Mapping  into  a  common 
ontology,  and  the  refinement  of  thereof 
allow  evolving  knowledge 
representations  and  standards  to  be 
captures  in  one  logical  repository 

Provide  geo- 
referenced 
interoperable 
infonnation 

Translation  Agents 
provide  common 
conversion  utilities  for 
geo-referenced 
information  to 
maintain  a  single, 
integrated  view  of  the 
battlespace 

Successfully  shared  overlays  between 
GCCS-COP  and  ABCS-CTP 

Ease  the 

introduction  of  new 
participant  system 
interfaces 

Simple  GUIs  for  drag- 
n-drop  schema 
mapping  and 
translation  into  a 
common  ontology 

Systems  developers  are  able  to  rapidly 
create  interfaces  that  connect  their 
participant  system(s)  to  DOORS, 
allowing  system  operator  to  collaborate 
using  their  native  system  representations 
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Code  generation  of 
semantic  maps  into 
Translation  Agent  base 
objects  and 

SOAP/XML  interfaces 

Isolates  software  development  resources 
spent  of  interface  creation  and 
maintenance 

Allows  for  the  preservation  of  valuable 
system  resources,  extending  the  life  of 
legacy  systems  by  making  them 
interoperable  within  the  GIG 

Eliminate  local-to- 
local  vocabulary 
mismatch  or 
interoperability 
fissures 

Semantic  Mapping 
between  knowledge 
bases  using  XML 
Schema,  RDF, 
DAML+OIL  based 
ontology  for  C2/C4I 
Vocabulary  building 

Translation  Agent  code 
generation  of  schema 
mapping 

Seamless  interoperable  information  is 
able  to  be  exchanged  end-to-end  amongst 
DOORS  compliant  systems 

System  developers  needn’t  migrate 
legacy  system  architectures  to  new 
standards  but  create  interoperability 
gateways,  isolating  themselves  from 
baseline  changes 

DOORS  may  be  employed  as  a  baseline 
gateway  within  the  context  of  one 
system,  providing  a  smooth  transition 
between  versions 

Provide 

commander’s 

information 

exchange 

requirements 

DOORS  compliant 
interfaces  register, 
publish,  and  subscribe 
to  interoperable 
information  according 
to  commander’s  intent 

SOAP/XML  interfaces  and  Translation 
Agents  proved  successful  in  the  exchange 
of  objects  between  GCCS-COP  and 
ABCS-CTP  based  upon  operator’s  object 
exchange  selection  via  overlay  sharing. 

Provide  a  loosely 
coupled  interface 

DOORS  Client  Agents 
employ  SOAP/XML  to 
interface  with  the 
DOORS  Web  Service 

Eliminates  the  problems  of  tightly 
coupled  IPC  mechanism  in  lossy  network 
environments,  etc. 

Minimize 
bandwidth  and 
promote  reliable 
delivery 

DOORS  Client  Agents 
employ  SOAP/XML  to 
interface  with  the 
DOORS  Web  Service 

DOORS  uses  the  publish-subscribe 
metaphor  to  advertise  the  availability  of 
new  object  exchange  information  instead 
of  polling,  eliminating  the  number  and 
size  of  inter-process  communications. 
DOORS  Client  Agents  actively  retrieve 
information  based  upon  notification 
rather  than  a  pure  push  mechanism 

Key  Benefits 

DOORS  addresses  the  Joint  requirement  for  geo-registration  capability  documented  in 
Joint  Requirement  GRID  #  741,  and  fulfdls  the  joint  mission  need  to  have  a  geo- 
registered  object  sharing  capability  to  support  situational  awareness  and  collaborative 
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planning  among  disparate  systems  in  a  collaborative  environment.  Through  use  of  a  geo- 
referenced/collaborative  object/overlay  sharing  and  mediation  service  (such  as  DOORS), 
leveraging  the  NCES  infrastructure  publish/subscribe  synchronization  capability  on  the 
GIG,  the  complete  view  of  the  battlespace  ionosphere  would  be  extended  to  all  echelons 
and  integrate  any  participant  system. 

SAIC’s  Dynamic  Operational  Object  Registration  Service  (DOORS)  was  developed  in 
the  anticipation  that  a  properly  conceived  C2/C4I  vocabulary  of  domain  knowledge 
representation,  supported  by  an  ontology-driven  adaptive  system,  and  employing  meta¬ 
data  based  translation  services  (mapping  of  data  from  each  participating  system  to  a 
common  representation)  will  provide  the  requisite  basis  for  a  network-centric  enterprise 
data  mediation  service  that  addresses  current  interoperability  challenges.  DOORS 
provides  a  mechanism  to  exchange  interoperable  information  for  joint/combined  task 
force  operations  according  to  a  register-publish-subscribe  metaphor  that  reflects  the 
commander’s  information  exchange  requirements.  DOORS  populates  the  network  with 
precise,  well-structured  information  allowing  for  the  rapid  retrieval  of  tagged  and  staged 
operational  object  content  that  facilitates  interoperability.  Warfighters  employing 
DOORS  in  the  conduct  of  joint  and  coalition  task  force  or  inter-governmental  agency 
operations  supporting  homeland  security  will  effectively  interoperate  with  other  DOORS 
compliant  systems,  even  those  that  possess  disparate  mapping/visualization  and 
information  management  infrastructures,  resulting  in  information  superiority  via  the 
exchange  of  interoperable  information  and  shared  knowledge  —  available  to  multiple 
levels  and  nodes  bases  upon  need  and  choice.  This  level  of  interoperability  is  critical  for 
geo-spatially  and  temporally  registered  operational  object  information  that  comprise  the 
situation  awareness  and  understanding  aspects  of  a  common  operational  picture, 
including  support  for  “drill  down”  information  as  well.  DOORS  supports  the  type  of 
robust  data  exchange  and  rapid  integration  via  plug-n-play  capabilities  that  characterize  a 
“power  to  the  edge”  NCES.  DOORS  promotes  an  innovative,  integrated,  and  elegant 
solution  to  the  interoperability  of  C2/C4I  systems  residing  within  the  NCES  GIG. 


OTHER  APPLICATIONS 

DOORS  can  be  applied  to  as  a  candidate  component  solution  in  the  following 
applications: 

•  As  a  homeland  security  data  mediation  service  promoting  inter-governmental 
agency  interoperability. 

•  As  a  coalition  data  mediation  service  as  well  as  a  joint  NCES  infrastructure 
component. 

•  Asa  “system  type”  gateway  to  interface  operational  C2/C4I  systems  with  systems 
designed  for  modeling  and  simulation  (M&S),  testing,  training,  etc. 

•  As  a  baseline  migration  utility,  mediating  data  between  versions  of  the  same 
system. 

Potential  measures  of  effectiveness  and  measures  of  performance  for  the  proposed  ACTD 
include: 
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1 .  Accuracy  of  translation  between  information  representations  between  participant 
systems,  including  geo-registered  location  and  temporal  information 

2.  Ability  to  fuse  common,  relevant  operational  pictures  between  multiple 
participant  systems  with  disparate  mapping  and  information  management 
infrastructure  components 

3.  Ability  to  exchange  common  attributes  representing  amplifying  information 
related  to  situational  awareness 

4.  Ability  to  translate  message  into  overlay 

5.  Propagation  latency  between  users’  participant  systems,  i.e.,  map  rendering  to 
map  rendering  across  the  network 

6.  Simultaneous  accommodation  of  publish/subscribers  bounded  by  an  established 
DOORS  Service  workspace  session  within  the  network 

7.  Scalability  of  DOORS  Service  and  workspaces  within  the  network;  that  is, 
integration  of  the  Service  via  multiple  servers  and  NCES 
dissemination/replication  mechanisms 
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